This is very cool. Awesome work, @taylorstine. I request that others to take a look at this and comment. It does not include a default emailSender?

@gfosco No, I figured the documentation may have to be updated or something to show an example implementation. I can easily add one, but I just figured the implementation of sendEmail would vary, since it depends on the service being used (in my case AWS-SES).

A default implementation could use SES, it would just require some configuration in the AWS Cloud Console from the implementer.

Also, unless parse is still open to hosting a [email protected] email, we would also need the email address from which to send the emails

Because of our previous module support, I'd like to see the default be a Mailgun or Mandrill implementation, but I guess we could always add that later.

Cool, I'll look in to that. I've never used those before so I'll have to do some investigation.

This looks pretty sweet, odd timing too as I just submitted a pull request with support for a MailAdapter and Mailgun (#191), maybe we could bridge the two together?

@jamiechapman that sounds good. @gfosco would you rather we implement this now, or would you prefer the default implementation in a separate PR?

@taylorstine I'd like to accept @jamiechapman 's MailAdapter method. Are you okay with implementing SES through that?

👍 great job

Great work @taylorstine and @jamiechapman!

@gfosco 👍 I'm not sure if this is what we're talking about doing, but I think the best thing to do might be to allow a user to specify a sendEmail function (though it should be renamed) if they want to optionally send a customized email. If no sendEmail method is passed @jamiechapman MailAdapter would be used to send a more generic email, the way parse currently works, with just some text and a link.

@taylorstine definitely! Maybe we could take some inspiration from the Parse.Push JS SDK and implement something like Parse.Mail.send({...}), which as you can say would then be useful to send messages via other functions etc.

@jamiechapman I like that idea, where the user could specify options and based on those options we decide how to route the sending logic. The payload to send could be something like

{
  mailType: "VERIFY_EMAIL"
  links: {verify: "http://www.example.com/verify"}
  recipient: "[email protected]"
  subject: "Verify your email"
  text: "You are being asked to verify your email, click here http://www.example.com/verify"
}

And the user could specify a middleware type function to modify these parameters, with the default as a function that just returns this payload.

@taylorstine updated the pull request.

Lets consolidate discussion in #275

Closing this, looks like the eventual solution will come from issue 275.